دليل المطور لأنماط التصميم في بايثون: Singleton، وFactory، وObserver

في عالم هندسة البرمجيات، كتابة كود يعمل بشكل صحيح هي مجرد الخطوة الأولى. إن إنشاء برمجيات قابلة للتطوير والصيانة والمرونة هو السمة المميزة للمطور المحترف. وهنا يأتي دور أنماط التصميم. فهي ليست خوارزميات أو مكتبات محددة، بل هي مخططات عالية المستوى ومستقلة عن لغة البرمجة لحل المشكلات الشائعة في تصميم البرمجيات.

سيأخذك هذا الدليل الشامل في رحلة عميقة إلى ثلاثة من أنماط التصميم الأساسية والأكثر استخدامًا، منفذة في بايثون: Singleton، وFactory، وObserver. سنستكشف ماهيتها، ولماذا هي مفيدة، وكيفية تنفيذها بفعالية في مشاريع بايثون الخاصة بك.

ما هي أنماط التصميم ولماذا هي مهمة؟

تم وضع تصور أنماط التصميم لأول مرة من قبل "عصابة الأربعة" (GoF) في كتابهم الرائد، "Design Patterns: Elements of Reusable Object-Oriented Software"، وهي حلول مجربة لمشكلات التصميم المتكررة. إنها توفر مفردات مشتركة للمطورين، مما يسمح للفرق بمناقشة الحلول المعمارية المعقدة بكفاءة أكبر.

يؤدي استخدام أنماط التصميم إلى:

• زيادة قابلية إعادة الاستخدام: يمكن إعادة استخدام المكونات المصممة جيدًا عبر مشاريع مختلفة.
• تحسين قابلية الصيانة: يصبح الكود أكثر تنظيمًا وأسهل للفهم وأقل عرضة للأخطاء عند الحاجة إلى إجراء تغييرات.
• تعزيز قابلية التوسع: تكون البنية المعمارية أكثر مرونة، مما يسمح للنظام بالنمو دون الحاجة إلى إعادة كتابة كاملة.
• الترابط الضعيف (Loose Coupling): تكون المكونات أقل اعتمادًا على بعضها البعض، مما يعزز الوحداتية (modularity) والتطوير المستقل.

لنبدأ استكشافنا بنمط إنشائي يتحكم في إنشاء الكائنات: Singleton.

نمط Singleton: مثيل واحد للتحكم في كل شيء

ما هو نمط Singleton؟

نمط Singleton هو نمط إنشائي (creational pattern) يضمن أن للفئة مثيلًا واحدًا فقط ويوفر نقطة وصول عالمية وحيدة إليه. فكر في مدير تكوين على مستوى النظام، أو خدمة تسجيل (logging)، أو مجمع اتصالات قاعدة البيانات. لن ترغب في وجود مثيلات متعددة ومستقلة لهذه المكونات؛ أنت بحاجة إلى مصدر واحد وموثوق.

المبادئ الأساسية لنمط Singleton هي:

1. مثيل واحد (Single Instance): يمكن إنشاء مثيل للفئة مرة واحدة فقط طوال دورة حياة التطبيق.
2. وصول عالمي (Global Access): توجد آلية للوصول إلى هذا المثيل الفريد من أي مكان في الكود.

متى تستخدمه (ومتى تتجنبه)

نمط Singleton قوي ولكنه غالبًا ما يُساء استخدامه. من الضروري فهم حالات استخدامه المناسبة وعيوبه الكبيرة.

حالات استخدام جيدة:

• التسجيل (Logging): يمكن لكائن تسجيل واحد أن يركز إدارة السجلات، مما يضمن أن جميع أجزاء التطبيق تكتب في نفس الملف أو الخدمة بطريقة منسقة.
• إدارة التكوين: يجب تحميل إعدادات تكوين التطبيق (مثل مفاتيح API، علامات الميزات) مرة واحدة والوصول إليها عالميًا من مصدر حقيقة واحد.
• مجمعات اتصالات قاعدة البيانات: تعد إدارة مجمع اتصالات قاعدة البيانات مهمة تستهلك الكثير من الموارد. يمكن لنمط Singleton ضمان إنشاء المجمع مرة واحدة ومشاركته بكفاءة عبر التطبيق.
• الوصول إلى واجهة الأجهزة: عند التعامل مع قطعة واحدة من الأجهزة، مثل طابعة أو مستشعر معين، يمكن لنمط Singleton منع التعارضات الناتجة عن محاولات الوصول المتزامنة المتعددة.

مخاطر نمط Singleton (وجهة نظر النمط المضاد):

على الرغم من فائدته، غالبًا ما يُعتبر نمط Singleton نمطًا مضادًا (anti-pattern) لأنه:

• ينتهك مبدأ المسؤولية الواحدة: فئة Singleton مسؤولة عن منطقها الأساسي وعن إدارة دورة حياتها الخاصة (ضمان وجود مثيل واحد).
• يقدم حالة عالمية (Global State): الحالة العالمية تجعل من الصعب فهم الكود وتصحيحه. يمكن أن يكون للتغيير في جزء واحد من النظام آثار جانبية غير متوقعة في جزء آخر.
• يعيق قابلية الاختبار: المكونات التي تعتمد على Singleton عالمي تكون مرتبطة به بشدة. هذا يجعل اختبار الوحدات صعبًا، حيث لا يمكنك بسهولة استبدال Singleton بكائن وهمي (mock) أو بديل (stub) للاختبار المعزول.

نصيحة الخبراء: قبل اللجوء إلى نمط Singleton، فكر فيما إذا كان حقن التبعية (Dependency Injection) يمكن أن يحل مشكلتك بأناقة أكبر. إن تمرير مثيل واحد من كائن (مثل كائن التكوين) إلى الفئات التي تحتاجه يمكن أن يحقق نفس الهدف دون مخاطر الحالة العالمية.

تنفيذ نمط Singleton في بايثون

تقدم بايثون عدة طرق لتنفيذ نمط Singleton، ولكل منها مزاياها وعيوبها. أحد الجوانب الرائعة في بايثون هو أن نظام الوحدات (modules) الخاص بها يتصرف بطبيعته مثل Singleton. عندما تقوم باستيراد وحدة، تقوم بايثون بتحميلها وتهيئتها مرة واحدة فقط. عمليات الاستيراد اللاحقة لنفس الوحدة في أجزاء مختلفة من الكود ستعيد مرجعًا إلى نفس كائن الوحدة.

لنلقِ نظرة على تطبيقات أكثر وضوحًا تعتمد على الفئات.

التنفيذ 1: استخدام Metaclass

غالبًا ما يعتبر استخدام metaclass الطريقة الأكثر قوة و "بايثونية" لتنفيذ Singleton. تحدد الـ metaclass سلوك الفئة، تمامًا كما تحدد الفئة سلوك الكائن. هنا، يمكننا اعتراض عملية إنشاء الفئة.

            
class SingletonMeta(type):
    """A metaclass for creating a Singleton class."""
    _instances = {}

    def __call__(cls, *args, **kwargs):
        # This method is called when an instance is created, e.g., MyClass()
        if cls not in cls._instances:
            instance = super().__call__(*args, **kwargs)
            cls._instances[cls] = instance
        return cls._instances[cls]

class GlobalConfig(metaclass=SingletonMeta):
    def __init__(self):
        # This will only be executed the first time the instance is created.
        print("Initializing GlobalConfig...")
        self.settings = {"api_key": "default_key", "timeout": 30}

    def get_setting(self, key):
        return self.settings.get(key)

# --- Usage ---
config1 = GlobalConfig()
config2 = GlobalConfig()

print(f"config1 settings: {config1.settings}")
config1.settings["api_key"] = "new_secret_key_12345"

print(f"config2 settings: {config2.settings}") # Will show the updated key

# Verify they are the same object
print(f"Are config1 and config2 the same instance? {config1 is config2}")

            

              
                Copy
              
            
          

في هذا المثال، تعترض دالة `__call__` الخاصة بـ `SingletonMeta` عملية إنشاء مثيل لـ `GlobalConfig`. إنها تحتفظ بقاموس `_instances` وتضمن أنه يتم إنشاء وتخزين مثيل واحد فقط من `GlobalConfig` على الإطلاق.

التنفيذ 2: استخدام Decorator

توفر المزخرفات (Decorators) طريقة أكثر إيجازًا وقابلية للقراءة لإضافة سلوك Singleton إلى فئة دون تغيير بنيتها الداخلية.

            
def singleton(cls):
    """A decorator to turn a class into a Singleton."""
    instances = {}
    def get_instance(*args, **kwargs):
        if cls not in instances:
            instances[cls] = cls(*args, **kwargs)
        return instances[cls]
    return get_instance

@singleton
class DatabaseConnection:
    def __init__(self):
        print("Connecting to the database...")
        # Simulate a database connection setup
        self.connection_id = id(self)

# --- Usage ---
db1 = DatabaseConnection()
db2 = DatabaseConnection()

print(f"DB1 Connection ID: {db1.connection_id}")
print(f"DB2 Connection ID: {db2.connection_id}")
print(f"Are db1 and db2 the same instance? {db1 is db2}")

            

              
                Copy
              
            
          

هذا النهج نظيف ويفصل منطق Singleton عن منطق العمل الخاص بالفئة نفسها. ومع ذلك، يمكن أن يكون له بعض التفاصيل الدقيقة مع الوراثة والاستبطان (introspection).

نمط Factory: فصل عملية إنشاء الكائنات

بعد ذلك، ننتقل إلى نمط إنشائي قوي آخر: Factory. الفكرة الأساسية لأي نمط Factory هي تجريد عملية إنشاء الكائنات. بدلاً من إنشاء الكائنات مباشرة باستخدام المُنشئ (constructor) (على سبيل المثال، `my_obj = MyClass()`)، فإنك تستدعي دالة Factory. هذا يفصل كود العميل الخاص بك عن الفئات الملموسة (concrete classes) التي يحتاج إلى إنشائها.

هذا الفصل ذو قيمة لا تصدق. تخيل أن تطبيقك يدعم تصدير البيانات إلى تنسيقات مختلفة مثل PDF و CSV و JSON. بدون Factory، قد يبدو كود العميل الخاص بك هكذا:

            
if export_format == 'pdf':
    exporter = PDFExporter()
elif export_format == 'csv':
    exporter = CSVExporter()
else:
    exporter = JSONExporter()

exporter.export(data)

            

              
                Copy
              
            
          

هذا الكود هش. إذا أضفت تنسيقًا جديدًا (مثل XML)، فسيتعين عليك العثور على كل مكان يوجد فيه هذا المنطق وتعديله. يقوم نمط Factory بتركيز منطق الإنشاء هذا.

نمط Factory Method

يعرّف نمط Factory Method واجهة لإنشاء كائن ولكنه يترك للفئات الفرعية تغيير نوع الكائنات التي سيتم إنشاؤها. يتعلق الأمر بتأجيل عملية الإنشاء إلى الفئات الفرعية.

الهيكل:

• المنتج (Product): واجهة للكائنات التي تنشئها دالة Factory (مثل `Document`).
• المنتج الملموس (ConcreteProduct): تطبيقات ملموسة لواجهة المنتج (مثل `PDFDocument`، `WordDocument`).
• المنشئ (Creator): فئة مجردة تعلن عن دالة Factory (`create_document()`). يمكنها أيضًا تعريف دالة قالب (template method) تستخدم دالة Factory.
• المنشئ الملموس (ConcreteCreator): فئات فرعية تتجاوز (override) دالة Factory لإعادة مثيل لمنتج ملموس معين (مثل `PDFCreator` يعيد `PDFDocument`).

مثال عملي: مجموعة أدوات واجهة مستخدم متعددة المنصات

لنتخيل أننا نبني إطار عمل لواجهة المستخدم يحتاج إلى إنشاء أزرار مختلفة لأنظمة تشغيل مختلفة.

            
from abc import ABC, abstractmethod

# --- Product Interface and Concrete Products ---
class Button(ABC):
    """Product Interface: Defines the interface for buttons."""
    @abstractmethod
    def render(self):
        pass

class WindowsButton(Button):
    """Concrete Product: A button with Windows OS style."""
    def render(self):
        print("Rendering a button in Windows style.")

class MacOSButton(Button):
    """Concrete Product: A button with macOS style."""
    def render(self):
        print("Rendering a button in macOS style.")

# --- Creator (Abstract) and Concrete Creators ---
class Dialog(ABC):
    """Creator: Declares the factory method.
       It also contains business logic that uses the product.
    """
    @abstractmethod
    def create_button(self) -> Button:
        """The factory method."""
        pass

    def show_dialog(self):
        """The core business logic that isn't aware of concrete button types."""
        print("Showing a generic dialog box.")
        button = self.create_button()
        button.render()

class WindowsDialog(Dialog):
    """Concrete Creator for Windows."""
    def create_button(self) -> Button:
        return WindowsButton()

class MacOSDialog(Dialog):
    """Concrete Creator for macOS."""
    def create_button(self) -> Button:
        return MacOSButton()

# --- Client Code ---
def initialize_app(os_name: str):
    if os_name == "Windows":
        dialog = WindowsDialog()
    elif os_name == "macOS":
        dialog = MacOSDialog()
    else:
        raise ValueError(f"Unsupported OS: {os_name}")
    
    dialog.show_dialog()

# Simulate running the app on different OS
print("--- Running on Windows ---")
initialize_app("Windows")

print("\n--- Running on macOS ---")
initialize_app("macOS")

            

              
                Copy
              
            
          

لاحظ كيف تعمل دالة `show_dialog` مع أي `Button` دون معرفة نوعه الملموس. يتم تفويض قرار إنشاء الزر إلى الفئات الفرعية `WindowsDialog` و `MacOSDialog`. هذا يجعل إضافة `LinuxDialog` أمرًا سهلاً دون تغيير فئة `Dialog` أو كود العميل الذي يستخدمها.

نمط Abstract Factory

يأخذ نمط Abstract Factory هذا خطوة إلى الأمام. إنه يوفر واجهة لإنشاء عائلات من الكائنات المترابطة أو المعتمدة على بعضها دون تحديد فئاتها الملموسة. إنه مثل مصنع لإنشاء مصانع أخرى.

استمرارًا لمثال واجهة المستخدم الخاص بنا، لا يحتوي مربع الحوار على زر فقط؛ بل يحتوي على مربعات اختيار وحقول نصية والمزيد. يتطلب المظهر والملمس المتسق (السمة) أن تنتمي جميع هذه العناصر إلى نفس العائلة (على سبيل المثال، جميعها بنمط Windows أو جميعها بنمط macOS).

الهيكل:

• المصنع المجرد (AbstractFactory): واجهة مع مجموعة من دوال Factory لإنشاء منتجات مجردة (مثل `create_button()`، `create_checkbox()`).
• المصنع الملموس (ConcreteFactory): ينفذ المصنع المجرد لإنشاء عائلة من المنتجات الملموسة (مثل `LightThemeFactory`، `DarkThemeFactory`).
• المنتج المجرد (AbstractProduct): واجهات لكل منتج متميز في العائلة (مثل `Button`، `Checkbox`).
• المنتج الملموس (ConcreteProduct): تطبيقات ملموسة لكل عائلة منتجات (مثل `LightButton`، `DarkButton`، `LightCheckbox`، `DarkCheckbox`).

مثال عملي: مصنع سمات واجهة المستخدم

            
from abc import ABC, abstractmethod

# --- Abstract Product Interfaces ---
class Button(ABC):
    @abstractmethod
    def paint(self):
        pass

class Checkbox(ABC):
    @abstractmethod
    def paint(self):
        pass

# --- Concrete Products for the 'Light' Theme ---
class LightButton(Button):
    def paint(self):
        print("Painting a light theme button.")

class LightCheckbox(Checkbox):
    def paint(self):
        print("Painting a light theme checkbox.")

# --- Concrete Products for the 'Dark' Theme ---
class DarkButton(Button):
    def paint(self):
        print("Painting a dark theme button.")

class DarkCheckbox(Checkbox):
    def paint(self):
        print("Painting a dark theme checkbox.")

# --- Abstract Factory Interface ---
class UIFactory(ABC):
    @abstractmethod
    def create_button(self) -> Button:
        pass
    
    @abstractmethod
    def create_checkbox(self) -> Checkbox:
        pass

# --- Concrete Factories for each theme ---
class LightThemeFactory(UIFactory):
    def create_button(self) -> Button:
        return LightButton()
    
    def create_checkbox(self) -> Checkbox:
        return LightCheckbox()

class DarkThemeFactory(UIFactory):
    def create_button(self) -> Button:
        return DarkButton()
    
    def create_checkbox(self) -> Checkbox:
        return DarkCheckbox()

# --- Client Code ---
class Application:
    def __init__(self, factory: UIFactory):
        self.factory = factory
        self.button = None
        self.checkbox = None

    def create_ui(self):
        self.button = self.factory.create_button()
        self.checkbox = self.factory.create_checkbox()

    def paint_ui(self):
        self.button.paint()
        self.checkbox.paint()

# --- Main application logic ---
def get_factory_for_theme(theme_name: str) -> UIFactory:
    if theme_name == "light":
        return LightThemeFactory()
    elif theme_name == "dark":
        return DarkThemeFactory()
    else:
        raise ValueError(f"Unknown theme: {theme_name}")

# Create and run the application with a specific theme
current_theme = "dark"
ui_factory = get_factory_for_theme(current_theme)
app = Application(ui_factory)
app.create_ui()
app.paint_ui()

            

              
                Copy
              
            
          

فئة `Application` غير مدركة تمامًا للسمات. إنها تعرف فقط أنها بحاجة إلى `UIFactory` للحصول على عناصر واجهة المستخدم الخاصة بها. يمكنك تقديم سمة جديدة تمامًا (مثل `HighContrastThemeFactory`) عن طريق إنشاء مجموعة جديدة من فئات المنتجات ومصنع جديد، دون لمس كود العميل `Application` على الإطلاق.

نمط Observer: إبقاء الكائنات على اطلاع

أخيرًا، دعنا نستكشف حجر الزاوية في الأنماط السلوكية (behavioral pattern): نمط Observer. يحدد هذا النمط تبعية "واحد إلى كثير" بين الكائنات بحيث عندما يغير كائن واحد (الموضوع) حالته، يتم إعلام جميع توابعه (المراقبين) وتحديثها تلقائيًا.

هذا النمط هو أساس البرمجة القائمة على الأحداث. فكر في الاشتراك في نشرة إخبارية، أو متابعة شخص ما على وسائل التواصل الاجتماعي، أو الحصول على تنبيهات بأسعار الأسهم. في كل حالة، أنت (المراقب) تسجل اهتمامك بموضوع ما، ويتم إعلامك تلقائيًا عند حدوث شيء جديد.

المكونات الأساسية: الموضوع (Subject) والمراقب (Observer)

• الموضوع (Subject أو Observable): هذا هو الكائن محل الاهتمام. يحتفظ بقائمة من المراقبين ويوفر دوال لإرفاقهم (`subscribe`) وفصلهم (`unsubscribe`) وإعلامهم.
• المراقب (Observer أو Subscriber): هذا هو الكائن الذي يريد أن يتم إعلامه بالتغييرات. يعرّف واجهة تحديث (`update`) يستدعيها الموضوع عند تغير حالته.

متى تستخدمه

• أنظمة معالجة الأحداث: مجموعات أدوات واجهة المستخدم الرسومية هي مثال كلاسيكي. يقوم زر (الموضوع) بإعلام العديد من المستمعين (المراقبين) عند النقر عليه.
• خدمات الإشعارات: عند نشر مقال جديد على موقع إخباري (الموضوع)، يتلقى جميع المشتركين المسجلين (المراقبين) بريدًا إلكترونيًا أو إشعارًا فوريًا.
• بنية Model-View-Controller (MVC): يقوم النموذج (الموضوع) بإعلام العرض (المراقب) بأي تغييرات في البيانات، حتى يتمكن العرض من إعادة عرض نفسه لإظهار المعلومات المحدثة. هذا يبقي منطق البيانات ومنطق العرض منفصلين.
• أنظمة المراقبة: يمكن لمراقب صحة النظام (الموضوع) إعلام مختلف لوحات المعلومات وأنظمة التنبيه (المراقبين) عندما يتجاوز مقياس حرج (مثل استخدام وحدة المعالجة المركزية أو الذاكرة) حدًا معينًا.

تنفيذ نمط Observer في بايثون

إليك تنفيذ عملي لوكالة أنباء تقوم بإعلام أنواع مختلفة من المشتركين.

            
from abc import ABC, abstractmethod
from typing import List

# --- Observer Interface and Concrete Observers ---
class Observer(ABC):
    @abstractmethod
    def update(self, subject):
        pass

class EmailNotifier(Observer):
    def __init__(self, email_address: str):
        self.email_address = email_address

    def update(self, subject):
        print(f"Sending Email to {self.email_address}: New story available! Title: '{subject.latest_story}'")

class SMSNotifier(Observer):
    def __init__(self, phone_number: str):
        self.phone_number = phone_number

    def update(self, subject):
        print(f"Sending SMS to {self.phone_number}: News Alert: '{subject.latest_story}'")

# --- Subject (Observable) Class ---
class NewsAgency:
    def __init__(self):
        self._observers: List[Observer] = []
        self._latest_story: str = ""

    def attach(self, observer: Observer) -> None:
        print("News Agency: Attached an observer.")
        self._observers.append(observer)

    def detach(self, observer: Observer) -> None:
        print("News Agency: Detached an observer.")
        self._observers.remove(observer)

    def notify(self) -> None:
        print("News Agency: Notifying observers...")
        for observer in self._observers:
            observer.update(self)

    @property
    def latest_story(self) -> str:
        return self._latest_story

    def add_new_story(self, story: str) -> None:
        print(f"\nNews Agency: Publishing new story: '{story}'")
        self._latest_story = story
        self.notify()

# --- Client Code ---
# Create the subject
agency = NewsAgency()

# Create observers
email_subscriber1 = EmailNotifier("reader1@example.com")
sms_subscriber1 = SMSNotifier("+15551234567")
email_subscriber2 = EmailNotifier("another.reader@example.com")

# Attach observers to the subject
agency.attach(email_subscriber1)
agency.attach(sms_subscriber1)
agency.attach(email_subscriber2)

# The subject's state changes, and all observers are notified
agency.add_new_story("Global Tech Summit Begins Next Week")

# Detach an observer
agency.detach(email_subscriber1)

# Another state change occurs
agency.add_new_story("Breakthrough in Renewable Energy Announced")

            

              
                Copy
              
            
          

في هذا المثال، لا تحتاج `NewsAgency` إلى معرفة أي شيء عن `EmailNotifier` أو `SMSNotifier`. إنها تعرف فقط أنهما كائنات `Observer` لهما دالة `update`. هذا يخلق نظامًا مفككًا للغاية حيث يمكنك إضافة أنواع جديدة من الإشعارات (مثل `PushNotifier`، `SlackNotifier`) دون إجراء أي تغييرات على فئة `NewsAgency`.

الخاتمة: بناء برمجيات أفضل باستخدام أنماط التصميم

لقد رحلنا عبر ثلاثة أنماط تصميم أساسية — Singleton و Factory و Observer — ورأينا كيف يمكن تنفيذها في بايثون لحل التحديات المعمارية الشائعة.

• يمنحنا نمط Singleton مثيلًا واحدًا يمكن الوصول إليه عالميًا، وهو مثالي لإدارة الموارد المشتركة ولكن يجب استخدامه بحذر لتجنب مخاطر الحالة العالمية.
• توفر أنماط Factory (Factory Method و Abstract Factory) طريقة قوية لفصل عملية إنشاء الكائنات عن كود العميل، مما يجعل أنظمتنا أكثر وحداتية وقابلية للتوسيع.
• يمكّن نمط Observer من بناء بنية نظيفة قائمة على الأحداث عن طريق السماح للكائنات بالاشتراك في تغييرات الحالة في كائنات أخرى والتفاعل معها، مما يعزز الترابط الضعيف.

إن مفتاح إتقان أنماط التصميم ليس حفظ تطبيقاتها، بل فهم المشكلات التي تحلها. عندما تواجه تحديًا في التصميم، فكر فيما إذا كان نمط معروف يمكن أن يوفر حلاً قويًا وأنيقًا وقابلاً للصيانة. من خلال دمج هذه الأنماط في مجموعة أدوات المطور الخاصة بك، يمكنك كتابة كود ليس وظيفيًا فحسب، بل أيضًا نظيفًا ومرنًا وجاهزًا للنمو المستقبلي.